home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16258 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.6 KB
  1. Path: news.nyu.edu!schonberg!dewar
  2. From: dewar@cs.nyu.edu (Robert Dewar)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 9 Apr 1996 21:51:37 -0400
  6. Organization: Courant Institute of Mathematical Sciences
  7. Message-ID: <dewar.829101012@schonberg>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.828936837@schonberg> <828964950snz@genesis.demon.co.uk> <dewar.828987544@schonberg> <4kbuebINNrho@keats.ugrad.cs.ubc.ca> <dewar.829048603@schonberg> <4kets3$ic0@news-s01.ny.us.ibm.net>
  9. NNTP-Posting-Host: schonberg.cs.nyu.edu
  10. X-Newsreader: NN version 6.5.0 (NOV)
  11.  
  12. Mike notes/asks
  13.  
  14. >I'm a latecomer to this dispute, but this is not smart:
  15. >
  16. >    char buf[100];
  17. >    read(fd,buf,1000);
  18. >
  19. >By the way, how did all this get started?
  20.  
  21. Good question, I don't particularly see any dispute here. Obviously
  22. noone ever wrote code so obviously peculiar as your above example!
  23.  
  24. The exact code, which appeared in the GNAT runtime was a loop to
  25. read a file that had in the loop
  26.  
  27.      read(fd,p,16*1024);
  28.  
  29. to read the file in chunks of 16K. The last call exactly filled the
  30. remaining buffer which had been sized to exactly fit the size of the
  31. file.
  32.  
  33. This code worked fine for a long time on nearly all systems, and in fact
  34. if you read the spec should work on most systems. But it failed on Linux
  35. (and was immediately corrected, no big deal!) and the reason is that
  36. Linux has subtly different semantics. The issue was whether any of the
  37. so-called specs for read (POSIX or SPEC1170) were clear enough to
  38. determine which of the two observed implementation models was "right".
  39.  
  40. Turns out that no spec we could find (no one seems to have SPEC1170)
  41. precisely defined the specs.
  42.  
  43. The wandering off into whether the code involved was or was not a good
  44. idea (obviously it was not!) is irrelevant. I was just using this as
  45. an example of a portability problem caused by weak specifications.
  46. Peter takes the odd view that it is not a portability problem because
  47. the code was not well defined, and therefore not portable. This seems
  48. a bit of a useless observation--Peter has determined that only
  49. portable code is portable, not terribly useful :-).
  50.  
  51. Kazimir at first claimed that the spec clearly favored the Linux
  52. interpretation, then could not find any evidence and appealed to
  53. unwritten rules :-)
  54.  
  55.  
  56. But just to be clear, there is no dispute over whether the code as
  57. written was a good idea, it was simply an interesting example of
  58. a portability problem resulting from weak specs. The disussion
  59. showed to an extent that surprised even me that the specs for
  60. such routines are really horribly weak, at least in POSIX.
  61.  
  62.